Release 10.1A: OpenEdge Development:
Messaging and ESB


Client persistence

Client persistence provides a higher level of reliability than is defined in the JMS specification. Client persistence allows the JMS session to continue sending messages regardless of the SonicMQ Broker status. If the SonicMQ Broker is not available, the messages are stored locally and sent when the SonicMQ Broker becomes available.

Note: Client persistence is only available to 4GL clients running in ClientConnect and ServerConnect.

Storing undeliverable messages

When the connection to the SonicMQ Broker fails, messages are persisted to disk, and replayed when the connection is re-established. Each connection must have a local directory specified where messages will be stored when a connection fails.

Table 4–5 lists the methods for managing client persistence.

Table 4–5: Managing client persistence 
Setting
Getting

Additionally, client persistence requires using the setClientID procedure. The clientID must be unique for each client. The application may optionally call the setPingInterval procedure to enable connection checking between the client and the SonicMQ Broker.

Note: Creating a Rejected Message Listener is also optional. This listener notifies the client when a message is rejected during playback.

The caller must ensure that the connections to the machine and port number are correct. It is possible for messages to be lost if an incorrect broker is specified. Although the messages will be persisted to disk, they will never be sent since there will never be a broker to connect to.

Note: Client persistence does not support Message Consumers and transacted sessions.

For an example of client persistence, see the "Client persistence" section.


Copyright © 2005 Progress Software Corporation
www.progress.com
Voice: (781) 280-4000
Fax: (781) 280-4095